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(57) Abstract 

A funds transfer system described facilitates elelctronic funds transfer between two parties. The home banking system computer (40) 
is operable, upon receipt of the payment order from the payor station (30), to generate a universal identifier number uniquely identifying 
the payee and to transmit electronically the universal identifier number to the trusted third party via a communication with the trusted third 
party system. The trusted third party system computer (50) also being operable, in response to receipt of the universal identifier number 
from the home banking system, to identify the payee as a party to receive payment, to generate a routing/transit number of the bank of 
the payee and the payee's account number from the universal identifier number, and to commmunicate electronically with the bank of the 
payee to facilitate transfer of the amount owed to the payee's account to the bank of the payee. 
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TITLE 

ELECTRONIC FUNDS TRANSFER METHOD AND SYSTEM AND BILL 
PRESENTMENT METHOD AND SYSTEM 

BACKGROUND OF THE INVENTION 

Field of the Invention 

5 

The present invention, according to a first aspect, 
relates to an electronic funds transfer method and 
system, and, according to a second aspect, an 
electronic bill presentment method and system. 

10 

Related Background Art 

The current environment for payments involving business 
and banks is primarily a paper one. Businesses and 

15 banks have become masters of paper- -business in 
handling payment remittances and banks in check 
processing. This efficiency in paper processing has 
created a weak or non-existent electronic bill payment 
infrastructure. The majority of businesses cannot post 

20 electronic payment information directly . into their 

accounts receivable systems. The majority of banks do 
not have the ability to deliver remittance information 
to their business customers. 
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Banks are in a unique position at the center of the 
bill payment process. They hold the customer accounts 
from which payments are authorized and are uniquely 
positioned to deliver the remittance information to the 
5 biller. Banks are also positioned to deliver the 

invoice information to the billers' customers who are 
also the banks' customers. 

Despite the widespread availability of ATMs and direct 
10 deposit of paychecks, most consumers have not embraced 
electronic payment systems. Discussion will follow of 
several prior art payment systems . 

In conventional non- electronic bill payment systems, 
15 where an ongoing relationship exists, a party 

initiating payment (also referred to hereinafter as 
"payor" or "consumer") pays a debt to a biller by 
mailing a check in response to receipt of the biller' s 
invoice. The term biller is used to refer to the payee 
20 or entity to be paid. Attached to most biller' s 

invoices is a payment coupon to be returned with the 
check. The coupon contains at least the 

consumer-biller account number (C-B account number) , as 
well as other information that will assist the biller, 
25 or the biller' s bank, in properly crediting the 

consumer (i.e., the party initiating payment) with 
payment . 

In recent years, with the common appearance of personal 
3 0 computers (PCs) in the home, electronic home banking 
has become increasingly popular. Electronic home 
banking systems permit consumers to automate the 
process of making payments to companies and 
individuals. Payment instructions are typically 
35 initiated by the consumer (party initiating payment) 

from the home PC terminal and forwarded electronically, 
generally over a telephone line, to the consumer's bank 
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or other financial institution supporting home banking. 
In response to receipt of the payment instructions, 
payments are created by the bank or financial 
institution in a variety of methods. Payment 
5 instructions also have conventionally been transmitted 
via ATM or telephone touch tone keypad. 

In one type of prior art electronic home banking 
system, illustrated in Fig. 1, the electronic payment 
10 instructions initiated by the consumer are converted by 
a bill pay service bureau, which may or may not be a 
bank, to a paper check, which is then mailed to the 
biller B, for eventual deposit into biller's bank 
account in bank B. 

15 

The electronic home banking system illustrated in 
Fig. 1 includes: consumer C 12, bank C 16, bank B 18, 
possibly a lockbox operator (not shown in Fig. 1) , and 
biller B, who is typically not a willing participant in 

2 0 this system for reasons discussed further below. 

Additionally, a service bureau S 2 0 and a Bank S 22 are 
participants, with service bureau S maintaining a 
service database 24 that is used to match bill payment 
orders with billers. 

25 

In the bill pay system of Fig. 1, consumer C enrolls in 
the system by sending service bureau S an enrollment 
package comprising a voided check and list of billers 
to be paid by S on behalf of C. S subsequently sends 
30 biller B a biller confirmation to verify that C is 
actually a customer of B. 

In the conventional, i.e., paper, bill payment method, 
the proper biller is identified by the remittance 

3 5 envelope and the payment coupon. However, neither of 

these are available to service bureau S in the system 
illustrated in Fig. 1. Thus, service bureau S must 
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identify the correct biller for each bill payment order 
in some other manner. Typically, this is done by 
asking consumer C for biller B's name, address, 
telephone number and the C-B account number. Since it 
5 is possible that service bureau S does not have any 

account relationship with biller B, they must rely upon 
consumer C's accuracy in preparing enrollment package 
used to put biller B's information into service 
database 24. Service bureau S typically requires this 
10 information only once, during biller enrollment, 
storing it to service database 24 for use with 
subsequent payments directed to the same billers. 

At some point after enrollment, consumer C receives a 
bill and initiates a bill payment order to S. The bill 
payment order includes authorization for service bureau 
S to withdraw funds from C's account in bank C to pay 
the bill, the amount to pay, the date on which to pay, 
and an indication of biller B as the payee. Service 
bureau S responds by confirming receipt of the bill pay 
order. Consumer C can send the bill pay order in any 
number of ways, such as using a personal computer and 
modem, directly or through a packet or other data 
network, via an automatic teller machine (ATM) , video 
touch screen, a screen phone, or telephone Touch-Tone™ 
pad interacting with a voice response unit (VRU) . 
However this is done, service bureau S receives one or 
more bill pay orders from consumer C. These orders 
could be instructions to pay some amount for a 
particular bill or a set amount of money at periodic 
intervals . 

Once service bureau S has confirmed that biller B is 
the biller that consumer C desired to pay with the bill 
3 5 pay order, service bureau S passes the funds to biller 
B after securing funds to cover the remittance. Bill 
payment can take several forms. A "check and list" is 



20 



25 
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common in the art. A check and list comprises a single 
payment, a check drawn on service bureau S's account in 
bank S, accompanied by a list of all consumers whose 
individual remittances are aggregated in the single 
5 check. The list shows C-B account numbers and payment 
amounts for each consumer included on the list that 
should total to the amount of the single check. 

The system of Fig. 1 has several drawbacks. For one 
10 thing, in response to an invoice mailed to the 

consumer, the biller expects to receive: (1) a check 
directly from the payor, along with (2) the payment 
coupon having encoded thereon, among other things, the 
C-B account number. Receipt of the check from the bill 
15 pay service S, rather than from the consumer, and 

without the coupon, must be treated by the biller as an 
exception item, which generates a great deal of 
additional expense for the biller. 

2 0 Moreover, from the point of view of the consumer 

(payor) , such a system implementation is inconvenient 
at least because of the time delays involved in 
preparing the check. The consumer might assume that, 
because the transfer was initiated electronically, the 
25 payment to tl^e filler was instantaneous , or at least 

performed more rapidly than if the consumer had mailed 
the check himself. In reliance upon this belief, the 
consumer might delay initiating a payment longer than 
he would if paying by his own check. Such a delay 

3 0 could result in late payments and customer relations 

headaches for the bill paying bureau. 

Additionally, the system illustrated in Fig. 1 requires 
enrollment by the consumer in the system and requires 
35 that the consumer have a continuing relationship with 
the biller. Thus, this system is not useful for 
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processing one-time, or infrequent, financial 
transactions . 

Some of these problems could be solved by a system in 
5 which payment actually is made to the biller (payee) 
electronically, rather than by check. In one such 
system, described in U.S. Patent 5,465,206, issued to 
Hilt et al., participating consumers pay bills to 
participating billers through a payment network. The 
10 participating consumers receive bills from 

participating billers (paper/mail bills, e-mail 
notices, implied bills for automatic debts) that 
indicate an amount owed, and a unique biller 
identification number (BRN) . 

15 

In the Hilt et al . system, to authorize a remittance, 
the consumer transmits to its bank (also a participant 
in the system) a bill pay order indicating a payment 
date, a payment amount, the C-B account number, a 

2 0 source of funds and the BRN. The consumer's bank then 

submits a payment message to a payment network, and the 
payment network, which assigns the BRN's, forwards the 
payment message to the biller' s bank. For settlement, 
the consumer's bank debits the consumer's account and 
25 is obligj.t ';;d io a net position \;itl. the payment 

network; likewise, the biller' s bank receives a net 
position from the payment network and credits the 
biller' s bank account. The biller' s bank, upon receipt 
of the payment message, releases the funds to the 

3 0 biller, and provides Accounts Receivable (A/R) data to 

biller in a form that the biller has indicated, the 
form being one that does not have to be treated as an 
exception item to the biller, unlike in the system of 
Fig. l. The biller' s bank is assured of payment by the 
35 payment network, unless the transaction is a reversible 
transaction according to the preset rules of the 
payment network. In specific embodiments of the Hilt 
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system, the consumer initiates the bill pay orders 
manually, via paper, at an ATM, via PC, or via 
telephone keypad. 

5 However, because, in the Hilt system, the consumer 
initiating payment must know, among other things, a 
special identifier that uniquely identifies the biller, 
in this case the biller' s BRN, this system is of 
limited usefulness for transactions between parties 

10 that do not have an ongoing relationship, where the 
consumer will likely only know the biller' s name and 
address. In addition, the BRN's, which correspond to 
billers' account numbers, are disseminated to all 
payors, which may not be optimal for reasons of 

15 security. 

Thus, the need exists for a system and method that 
would enable the payor to initiate an electronic 
payment without knowledge of a special identifier 
20 corresponding to the biller' s bank and account number. 

The need also exists for a system by which billers can 
present bills to payors electronically. 

25 SUMMARY OF THE INVENTION 

It is an object of the present invention to solve the 
aforementioned problems of prior art systems by 
providing a method by which the confidential 
information of a first party be uniquely identified 

3 0 based upon name and address information supplied by a 
second party without the need for the second party to 
have access to the confidential information. 

It is another object of the present invention to solve 
3 5 the aforementioned problems of prior art systems by 
providing an electronic funds transfer method and 
system in which the biller' s routing number and account 
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number can be uniquely identified by the electronic 
home banking system based upon consumer supplied biller 
name and address information without the need for the 
consumer's bank to have access to the biller' s bank 
5 account number and in which payment can be made 
electronically to the identified account. 

It is a further object of the invention to provide an 
electronic home banking method and system that protects 
10 the security of bank customers and their bank's 
proprietary interests, without unnecessarily 
distributing information regarding bank affiliation or 
account number. 

15 It is a further object of the invention to provide a 
method and system of electronic bill presentment that 
permits billers to present bills to payors at the 
payors home banking systems without the need for the 
biller to have access to information regarding the 

2 0 payor ' s bank . 

To further these objects, a funds transfer system for 
facilitating electronic funds transfer between a payor 
and a payee by means of an intermediate trusted third 

2 5 party is provided. The funds transfer syscsm 

comprises: a payor station including a device for 
electronic communication of a payment order, said 
payment order comprising the payee's name, address and 
an amount owed by the payor to the payee; a home 

3 0 banking system including a computer structured to 

communicate electronically with the payor station, to 
receive the payment order, and with the trusted third 
party; a trusted third party system associated with the 
trusted third party, the trusted third party system 
35 comprising a computer structured to communicate 

electronically with both the home banking system and a 
bank of the payee. The home banking system computer is 
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operable, upon receipt of the payment order from the 
payor station, to generate a universal identifier 
number uniquely identifying the payee and to transmit 
electronically the universal identifier number to the 
5 trusted third party via a communication with the 

trusted third party system. The trusted third party 
system computer is operable, in response to receipt of 
the universal identifier number from the home banking 
system, to identify the payee as a party to receive 

10 payment, to generate a routing/transit number of the 
bank of the payee and the payee's account number from 
the universal identifier number, and to communicate 
electronically with the bank of the payee to facilitate 
transfer of the amount owed to the payee's account to 

15 the bank of the payee. Preferably, the home banking 

system computer has stored therein a database, supplied 
by the trusted third party, including name and address 
information of the payee and the universal identifier 
number, and not including corresponding routing/transit 

2 0 and account number information of the payee. 

To further these objects, a method of electronic funds 
transfer between a payor and a payee by an intermediate 
trusted third party is provided. The method comprises 
25 the steps of: upon receipt by the trusted third party 
of a universal identifier number uniquely identifying 
the payee and generated, in response to a payment order 
from the payor, by a home banking system of the payor 
from information stored on a database resident at the 

3 0 home banking system, generating, at the trusted third 

party, from the received universal identifier number a 
routing /trans it number of the payee's bank and the 
payee's account number to identify the payee as a party 
to receive payment, the routing/transit number of the 
3 5 payee's bank and the payee's account number being known 
only to the trusted third party; and communicating, by 
the trusted third party, with payee's bank to 
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facilitate transfer of an amount owed by the payor to 
the payee to the payee's account in the payee's bank. 
The method preferably further comprises the steps of 
generating the database at the trusted third party, the 
5 database including name and address information of the 
payee and the universal identifier number uniquely 
identifying the payee, and not including corresponding 
routing/transit and account number information of the 
payee, and distributing, before the routing/transit 
10 number generating step, the database to the home 
banking system. 

To further the above objects, there also is provided a 
funds transfer system for facilitating electronic funds 
15 transfer between a home banking system of a payor and 
an account of a payee. The system comprises: a 
trusted third party structured to communicate with both 
the home banking system and a bank of the payee 
maintaining payee's account, means associated with the 

2 0 home banking system for transmitting a universal 

identifier number to the trusted third party in 
response to receipt by the home banking system of a 
payment order from the payor, the universal identifier 
number uniquely identifying the payee; means associated 
25 with the trusted third party operable in response to 
receipt of the universal identifier number from the 
home banking system to identify the payee as a party to 
receive payment, and for converting the universal 
identifier number so as to identify the routing/transit 

3 0 number of the payee's bank and the payee's account 

number; and means associated with said trusted third 
party for communicating with payee's bank to facilitate 
payment in accordance with payor's payment order to 
payee ' s account . 

35 

To further the above objects of the present invention, 
there also is provided a method for electronic bill 
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presentment between a biller and a payor by a trusted 
third party intermediary. The method comprises: 
generating, by the trusted third party, a database 
including name and address information of the payee and 
5 a universal identifier number uniquely identifying the 
payee, and distributing the database to a home banking 
system of the payor; receiving, at the trusted third 
party, a biller order from the biller, the biller order 
comprising the payor's name, address and an amount to 

10 be paid by the payor to the biller; upon receipt by the 
trusted third party of the biller order, generating, at 
the trusted third party, a bill routing message and 
transmitting the bill routing message to the payor's 
home banking system, the message including the 

15 universal identifier number corresponding to the payor; 
and upon receipt by the home banking system of the bill 
routing message from the trusted third party, routing, 
by the home banking system, a bill to the payor 
corresponding to the bill routing message. The trusted 

2 0 third party preferably routes the bill to the payor 

using an ACH message formed based upon routing 
information resident in a master database resident at 
the trusted third party. 

25 To further the above objects of the present invention, 
there also is provided a method of electronic funds 
transfer between a payor and a payee by an intermediate 
trusted third party, the trusted third party having 
previously distributed to a home banking system of the 

3 0 payor a database including universal identifier numbers 

uniquely identifying accounts including that of the 
payee. The method includes the steps of: receiving, 
at the home banking system, a payment order from the 
payor; upon receipt by the home banking system of the 
35 payment order, identifying, at the home banking system, 
the universal identifier number uniquely identifying 
payee's account from information stored in the 
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database; and transmitting, by the home banking system, 
the universal identifier number identified in the 
identifying step, to the trusted third party to 
facilitate payment to payee's account. 

5 

To further the above objects of the present invention, 
there also is provided a computer- readable medium for 
storing data for access by an application program being 
executed on a data processing system resident at a 

10 trusted third party that has been supplied with 

confidential information of customers of at least one 
participating institution. The medium comprises: a 
data structure stored in the computer- readable medium, 
the data structure including information resident in a 

15 database used by the application program and 
comprising: a plurality of descriptors, each 
descriptor including a set of indicia identifying name, 
address, and the confidential information for one of 
the customers of the at least one participating 

20 institution, and a universal identifier uniquely 
identifying the one customer. Preferably, the 
confidential information comprises routing /trans it 
number and account number information associated with 
each customer. 

25 

To further the above objects of the present invention, 
there also is provided a method of transferring funds 
from a home banking system of a payor to an account of 
a payee. The method comprises the steps of: upon 

3 0 receipt by the home banking system of a payment order 
from the payor that includes character information, 
encoding the received character information by 
assigning a numerical value to identified nonblank 
character strings present in the received character 

3 5 information; forming a descriptor of indicia 

identifying the payee using the encoded numerical 
information; comparing the formed descriptor with 
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database descriptors stored in a database supplied by a 
trusted third party until a match is found; and 
transmitting a universal identifier, associated in the 
database with the matching database descriptor and 
5 uniquely identifying the payee, to the trusted third 
party to facilitate payment to payee's account. 

To further the above objects of the present invention, 
there also is provided a web-based bill presentment 
method for presenting bills by a biller to a payor 
using a trusted third party having a resident database 
including an e-mail address of the payor, the payor 
being a customer of a bank that has a bill presentment 
server. The method comprises: receiving, at the 
trusted third party, a bill presentment order from the 
biller; and in response to an inquiry from the bill 
presentment server of payor's bank, transmitting 
billing information of the biller to the payor's bank, 
which in turn, by means of the bill presentment server, 
presents the bill for display to the payor using the e- 
mail address of the payor. Preferably, display means 
linked to the bill payment server is made available to 
the payor, and the payor indicates a willingness to pay 
the bill by clicking a payment icon displayed by the 
display means and associated with the bill. 

To further the above objects of the invention, there 
also is provided a method of correlating between at 
least two entities by an intermediate trusted third 
3 0 party. The method comprises the steps of: receiving, 
by the trusted third party, a universal identifier 
number uniquely identifying a first one of the at least 
two entities and generated in response to a inquiry 
from a second one of the at least two entities from 
35 information stored on a database; and generating, at 
the trusted third party, from the received universal 
identifier number confidential information relating to 



15 



20 
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the first one of the at least two entities to identify 
the first one, the confidential information being known 
only to the trusted third party. 

5 The method preferably further comprises the steps of: 
generating the database at the trusted third party, the 
database including name and address information of the 
first one of the at least two entities and the 
universal identifier number uniquely identifying the 
10 first one, and not including corresponding confidential 
information of the first one, and distributing, before 
the confidential information generating step, the 
database so as to facilitate access to the database by 
the second one of the at least two entities. 

15 

Further objects, features and advantages of the present 
invention will become apparent from the following 
description of the preferred embodiments with reference 
to the attached drawings. 

20 

BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 is a block diagram of a conventional electronic 
bill paying system utilizing a bill pay service bureau; 

25 

Fig. 2A is a block diagram of the electronic banking 
system according to the present invention; 

Fig. 2B is a block diagram of the structure of the 
3 0 payor station according to the present invention; 

Fig. 2C is a block diagram of the structure of the 
computer system resident at payor's bank; 

3 5 Fig. 2D is a block diagram of the structure of the 
computer system resident at the trusted third party. 
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Fig. 3 is a diagram illustrating the operation of the 
payor' s home banking system in an embodiment of the 
present invention; 

5 Fig. 4 illustrates the operation of the token encoding 
process that takes place at the payor's home banking 
system; 

Fig. 5 illustrates the format of the database 
10 descriptor; 

Figs. 6(a) and 6(b) illustrate the format of a database 
payee record; 

15 Fig. 7 is a diagram illustrating the flow of 

information into and out of the trusted third party; 

Figs. 8A and 8B show an example of descriptor inclusion 
and shifting of over- descriptors , respectively; 

20 

Fig. 9 is a flowchart illustrating the logical flow of 
the check for descriptor inclusion; 

Fig. 10 is a flowchart illustrating the match program 
25 executed at the trusted third party ; 

Fig. 11 is a program and data flow diagram illustrating 
a batch matching job at the trusted third party; and 



3 0 Fig. 12 is a flowchart illustrating the descriptor 

generator program resident at the trusted third party. 
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DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

I, Electronic Funds Transfer 

5 The electronic funds transfer method and system 
according to the present invention will now be 
described in accordance with a preferred embodiment. 
Although the system is described herein as it relates 
to home banking, it can be used by any party wishing to 

10 initiate payments electronically, preferably through 

the Automated Clearing House (ACH) network, for example 
by means of the New York Automated Clearing House, 
which is trusted to have access to account information 
for all customers of its member banks. Moreover, the 

15 method is not limited to a method of transferring funds 
but may be utilized for any application that requires a 
correlation between two entities in which confidential 
information is to be made known only to a trusted third 
party intermediary. 

20 

The ACH network is a low- cost electronic payment 
mechanism that can be used efficiently to pay both 
individual consumers and companies, regardless of size. 
The system is flexible and highly reliable and 

25 incorporates th^ use of national standards. In order 
to use the ACH network, bank routing information and 
the payee (demand deposit account (DDA) identifier) 
account number must be supplied. This information must 
either be supplied by the initiator of the payment, or 

3 0 must be retained by the banking system of the payor 

("home banking system"). This presents a major problem 
that inhibits widespread use of the ACH since bank 
routing and account information of the payee is rarely 
conveyed to payors for use in initiating payment 

35 instructions since this information is not generally 
disseminated. Banks also are often reluctant to share 
this information with unrelated third parties, 
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including other banks. At best, therefore, most payors 
only know the payee's name and address, and, in certain 
situations, such as where an ongoing relationship 
exists, the C-B account number. 

5 

The present invention solves this problem by making use 
of the facilities of a trusted third party (TTP) 
intermediary, preferably an automated clearing house, 
such as the NYACH, to gain easy access to the ACH 
10 network by home banking systems, while maintaining 
transparency to the end user. 

To achieve this goal, a database of, among other 
things, payee name, address, routing number, DDA 

15 account number, and preferably taxpayer ID information, 
is developed that enables home banking systems, 
previously provided with information from the database 
that does not include the routing number and DDA 
account numbers, to generate ACH messages uniquely 

2 0 identifying the biller to the TTP and that can be 
translated by the TTP to bank routing and account 
information, thus facilitating use of the ACH to effect 
payments without unnecessarily distributing the routing 
number and account number information. 

25 

The technology used to develop the system is adapted 

from the Clearing House Interbank Payments System 

(CHIPS) Universal Identifier (UID) database system. 

CHIPS, established in 19 70, processes international and 
30 domestic payments electronically and is the foremost 

means of transferring U«S. dollars among world banks. 

In the CHIPS a universal identifier number is utilized 

that uniquely identifies individual customer accounts. 

The CHIPS UID number is a six- digit number that is used 
35 to identify named accounts at depository institutions 

on the CHIPS system, uniformly across the system, since 

CHIPS' inception in 1970. 
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In the present invention, a universal identifier (UID) 
number, not necessarily or preferably corresponding to 
the CHIPS format, is assigned to correspond to each 
biller. The TTP, and only the TTP, can correlate the 
5 biller' s UID with the biller' s routing number and 
account number. However, as will be described in 
detail below, since a database containing the biller 
names and addresses, and associated UID's, has been 
distributed to the home banking systems, the home 

10 banking systems, using software supplied by the trusted 
third party, can produce a UID when supplied by a party 
initiating payment with the biller' s name and address. 
A home banking system of the party initiating payment 
can then create ACH payment messages, for example, in 

15 customer initiated entry (CIE) format, for consumer to 
business transactions, and in PPD format, for business 
to consumer transactions, from payor- initiated 
instructions without having access to biller bank 
routing and account number data, and forward these to 

20 the TTP, trusted by all participants to hold onto this 
data, whose computer system will interpret the received 
message to determine the bank routing and account 
number of the biller to whom payment is to be sent. 
Message formats for ACH transactions are set forth in 

25 "1998 ACH Rules", available from :ha National Automated 
Clearing House Association, 607 Herndon Parkway, Suite 
200, Herndon, VA 20170, starting at page OR 28. 

A CIE entry is defined as a credit entry initiated by 
3 0 or on behalf of the holder of a consumer account to 
affect a transfer of funds to the deposit account of 
the Receiver. "CIE+" is a CIE entry with one addenda 
record. A PPD entry is defined as a credit or debit 
entry (other than MTE or POS entry) initiated by an 
35 organization pursuant to a standing or single entry 
authorization from a Receiver to effect a transfer of 
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funds to or from a consumer account of the Receiver. 
"PPD+" is a PPD entry with one addenda record. 

An ACH message normally includes, among other things, 
5 an account number field and a routing number field. To 
implement the present invention, a UID number, 
previously assigned by the TTP and uniquely identifying 
the biller, is placed by the home banking system in the 
account number field of an ACH message and a special 

10 identifier flag, e.g., all 9's, is placed in the 

routing number field to identify the message as one 
requiring special treatment. The TTP recognizes the 
special identifier flag is present in the routing 
number field, indicating to the TTP receiving the ACH 

15 message that special treatment of the message is 

necessary. The trusted third party then performs a 
lookup of the actual routing number and account number 
at a central database using the supplied ACH UID, 
substitutes the stored routing and account numbers that 

2 0 correspond to the UID into the ACH message for the 

special identifier and received UID, respectively, and, 
once the substitution has been made, completes 
processing of the payment through the ACH network in 
the same manner as any other ACH transaction. The 
25 result is an electronic payment received in a timely 

and accurate fashion at reduced cost to the originating 
financial institution. Advantageously, in the present 
invention the payor's home banking system knows the 
UID, but does not know the biller' s account /routing 

3 0 number, increasing the confidentiality of the system. 

A preferred embodiment of the system for implementing 
the present invention will now be discussed with 
reference to Fig. 2A. As shown in Fig. 2 A, the system 
35 components include the entity initiating payment 10 

(the "consumer" or "payor"), the consumer's bank C 12 
(payor's home banking system), trusted third party 
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(TTP) 13, payee's Bank B 16 , and payee B 11, The 
entity initiating payment 10, is equipped with a payor 
station 30, preferably consisting of a personal 
computer and modem for electronically communicating 
5 over a phone line, although the payor station may 

comprise an ATM or a telephone touch- tone key pad, or 
other similar device. 

Fig. 2B illustrates the components of the payor station 
10 3 0 in block diagram form. The payor station 3 0 

includes a CPU 31 that performs processing functions. 
The payor station 3 0 also includes a read only memory 
32 (ROM) , which stores at least some of the program 
instructions to be executed by CPU 31, such as portions 
15 of the operating system or basic input -output system 
(BIOS) , and a random access memory 33 (RAM) used for 
temporary (e.g. scratchpad) storage of data. 

The payor station 3 0 also includes customer network 
2 0 interface 72 which enables the payor station 3 0 to 

communicate with external devices. In particular, the 
data network interface 72 enables communication between 
the payor station 3 0 and bank C (which constitutes the 
payor's home banking system), more specifically bank 
25 computer system 40. The interface preferably comprises 
a modem and a dedicated telephone line. However, other 
network interfaces, such as an ISDN terminal to 
interface with an ISDN network, or an Internet 
interface, may be used as well. 

30 

A data storage device 34 is provided to allow for 
storage of data. Data storage device 34 may be written 
to or read from by the CPU 31. Data/Address bus 37 
connects the ROM 32, RAM 33 and data storage device 34 
35 to the CPU. A keyboard 3 5 is provided to receive input 
from the payor 10. Input from the payor 10 may be 
provided instead by a mouse (not shown) , or by any 
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conventional method of operator input. A display 3 6 is 
provided for conveying information to the operator of 
the payor station 30. 

5 To initiate payment of an outstanding debt to payee 
B 11 in this embodiment, payor 10 sends, by means of 
payor station 30' s network interface, a payment order 
to bank C 12, which is received by bank computer system 
40. The payment order preferably includes payee name 

10 and address information, the amount to be paid, and 
optional reference data identifying the payor. In a 
case where an ongoing relationship exists between the 
payor and the payee, the payor's account number can be 
used to identify the payor. Where no such ongoing 

15 relationship exists, the payor's name may be employed 
as the optional reference data. 

Bank C 12 is equipped with a computer system 40, which 
is illustrated, in block diagram form, by Fig. 2C. As 

2 0 shown in Fig. 2C, bank computer system 40 preferably 

includes a CPU 41, ROM 42 and RAM 43. Bank computer 
system 4 0 also includes a customer network interface 
82, to enable electronic communication with the payor 
station 3 0 over a phone line, ISDN network, or via the 
25 Internet, and an ACH data network interface 83, to 
enable communication over the ACH network, in 
particular with the trusted third party computer system 
50 resident at the trusted third party 13. Bank 
computer system 40 includes a data storage device 44 on 

3 0 which is stored a token/descriptor database 15 that has 

previously been supplied by the TTP. Data/address bus 
45 connects the ROM 42, RAM 43 and data storage device 
44 to the CPU 41. 

3 5 Fig. 2D illustrates the trusted third party computer 

system 50, resident at the trusted third party 13. The 
trusted third party computer system includes a CPU 51, 
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a ROM 52, a RAM 53 and a data storage device 54. 
Data/address bus 55 connects the ROM 52, RAM 53 and the 
data storage device 54 to the CPU 51. An ACH data 
network interface is provided which enables 
5 communication over the ACH system, in particular with 
the bank C 12 and biller's bank B 16, as well as any 
institution on the ACH network. 



Although the connections between the bank C computer 
10 system and the TTP, as well as the connection between 
the TTP and biller's bank B are illustrated in Fig. 2A 
as direct connections, in actual practice, electronic 
communication between these parties may utilize 
intermediate ACH operators between the parties to 
15 facilitate the communication. Any reference to 
electronic communication between the parties is 
intended also to cover communication through such 
intermediaries . 



2 0 Token/descriptor database 15, resident in the data 

storage device 44 of bank C's computer system 40, 
includes descriptors with encoded keys corresponding to 
the name and address tokens of each of the billers 
supplied by participating banks. Software, also 
25 supplied by the TTP, resident on bank C's computer 

system 40 associates the name and address transmitted 
by the payor with the account of a particular biller. 
This is achieved by first forming a descriptor data 
structure corresponding to the information input by the 

3 0 payor and then finding a match from among the 

descriptors stored in the resident token/descriptor 
database that has been previously supplied by the TTP. 
The database descriptors stored in the token/descriptor 
database each have appended thereto, or associated 
35 therewith, among other information, a universal 

identifier number (UID) , previously generated by the 
TTP, that uniquely identifies the payee so that when a 
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match is found between the descriptor generated in 
response to the input name and address and one of the 
descriptors stored in the token/descriptor database, 
the UID for the payee is identified. Each participant 
5 in the instant electronic funds transfer system, such 
as bank C, is supplied with the token/descriptor 
database to allow payments to be made by and to 
customers of the respective banks. 

The software supplied to bank C by the TTP and resident 
in bank C's computer system 40 identifies the 
corresponding UID by means of a process illustrated in 
Fig. 3. As shown in that figure, after the payor has 
transmitted the name and address information of the 
biller (preferably together with the amount to be paid 
and the optional reference data) at S10, the name and 
address are tokenized, that is, broken down into 
constituent non-blank character strings (tokens) and 
encoded at S20. This is done by the process shown in 
Fig. 4. As shown in Fig. 4, the text input by the 
payor (which constitutes a payment field) is scanned at 
S20A until a blank character is located. The non-blank 
character string preceding the blank forms the first 
token. The process is repeated until all the input 
text has been tokenized. 

Once the input characters have been tokenized, the 
tokens for the name, address and city entries are 
encoded at S20B to form encoded keys. Encoding of the 
3 0 tokens involves assignment to each token a 

corresponding number, or encoded key, as it will be 
referred to hereinafter. Once the tokens have been 
encoded, the encoded keys are placed in the various 
fields of the descriptor array (name and address and 
3 5 city) at S2 0C, the encoded keys resident in each 

descriptor field group are then sorted at S20D, by any 
conventional sorting method, so that the highest values 



15 



20 
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of the encoded keys, corresponding to the rarest words, 
are placed first within that group. State information 
is not encoded but is stored as alphanumeric 
information corresponding to the two- letter designation 
5 for the state used by the U.S. Postal Service. Five- 
digit and four- digit zip codes are also not encoded but 
simply stored in respective fields as numerical 
entries . 

10 For encoding, it is preferable that most commonly used 
words have associated keys available in a lookup table. 
Such a lookup table contains a list of tokens, and in a 
second field, a number associated with each token. 
Encoding is the most processor- intensive part of the 

15 name identification system. The inventors have 

achieved satisfactory performance from an encoding 
procedure based on a binary search preceded by table 
lookup of the first two characters of the token. 

2 0 Preferably, text input by the payor is subjected to 
preprocessing before encoding. Such preprocessing 
includes: (a) replacing special characters with space 
or null; (b) closing up (eliminating) null characters; 
(c) combining adjacent isolated single characters into 

25 a single token (e.g., IBM becomes IEM) ; (d) reducing 
multiple spaces to a single space; and (e) changing all 
letters to uppercase. 

Comparing encoded descriptors instead of using text 
30 comparison advantageously reduces descriptor size, 

since certain words, such as "noise" words (i.e., words 
that do not assist in identifying a name) , are never 
placed in the descriptor, and simplifies code, at least 
because number -encoded values can be stored in fields 
35 of fixed size, permitting more efficient machine code 
for the matching process. 
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Due to practical limitations on the size of the token 
list (lookup table) , for certain rare words, it may be 
more efficient to perform encoding by means of a 
hashing function that will, for any token, always 
5 assign it the same number (i.e., key). Such a function 
would be used both at the trusted third party for 
generating the token data base in the first place, a 
process described further below, and at the bank C for 
encoding the name and address information input by the 
10 consumer. All tokens encoded by the hashing technique 
will be considered rare and will have encoded values 
larger than the values assigned to tokens in the token 
lookup table. 

15 The process for matching the generated descriptor with 
the corresponding stored descriptor at payor's home 
banking system will now be described. As illustrated 
in Fig. 3, once the input name and address data has 
been tokenized and encoded, the generated payment party 

2 0 descriptor must be compared at S3 0 to the resident 
database 15 containing descriptor records of all 
participating payees to determine if there is a match. 
It is very important at the payor's home banking system 
(bank C) to avoid a false positive match between the 

2 5 descriptor generated from the data input by the 

consumer and the descriptors resident in the 
token/descriptor database, since such a match would 
result in payment being made where one was not 
intended. Accordingly, the preferred method of 

3 0 matching at the bank C is exact matching. In this 

method, for each field, a predetermined first number of 
the encoded keys are compared and must match exactly 
for a match to be declared for a given field. 

3 5 The descriptor format includes at least the following 
fields, some of which may be empty: 



WO 99/56219 



PCT/US99/09064 



- 26 - 



(1) Name of the individual or business 

(2) Several address lines 

(3) City 

(4) State 

5 (5) Five-digit zipcode 

(6) Four- digit zipcode extension 



Fig. 5 is a simplified representation of a database 
descriptor. Each such descriptor is generated at the 

10 TTP, in a manner to be discussed in further detail 

below, and supplied to each participant, such as bank 
C, as part of the token/descriptor database. Fig. 5, 
illustrates how the name, address and city information 
is encoded, that is, assigned encoded keys. In the 

15 example shown in the figure, the payee is National 

Mortgage Bank. For the name field, the word "Bank" is 
assigned the number l, the word "National" is assigned 
50, and "Mortgage" is assigned 60. The least commonly 
used words are assigned the highest numbers and placed 

20 first in the descriptor array, as shown in the figure. 
The same process is performed for the address, and city 
fields. Each descriptor also includes appended thereto 
the UID corresponding to the biller, as well as other 
information. 

25 

In response to the input of name and address 
information by the payor, a payee name and address 
descriptor is generated by the bank C. A simplified 
representation of a payee name and address descriptor 
30 is shown in Figs. 6(a) and 6(b) for the same payee as 

the one represented by the database descriptor shown in 
Fig. 5. 



Fig 6(a) shows the characters input by the consumer in 
the various fields of the descriptor. Fig. 6(b) shows 
the descriptor generated by the encoding and sorting 
programs resident on the bank's computer system. As 
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can be seen from Figs. 5 and 6 (a) - (b) , descriptors 
corresponding to the biller should be identical in each 
name and address field, that is, should exhibit an 
exact match. 

5 

Returning to the flowchart of Fig. 3, if a match is 
found during the comparison between the generated 
descriptor and one of the database descriptors, that 
is, if a database descriptor exists that exactly 

10 matches the generated payment party descriptor, the UID 
associated with the database entry is returned at S40 
and is placed into an ACH record. These records are 
incorporated into a file of ACH transactions that is 
then transmitted to the trusted third party for further 

15 processing at S50 and S60. If a match cannot be found, 
existing procedures for generating payments would be 
followed (not shown) . 

Two name descriptors are considered to match if an 
20 initial minimum number of keys are equal. (The minimum 
number may be set to the maximum if it is desired to 
force exact matching.) 

Note that since the keys that are required to match are 
25 those at the left ends of the two key groups, those 
keys are also the rarest keys in the groups, since 
encoded token numbers occur in decreasing order within 
a descriptor. Therefore, tokens with the highest 
encoded token numbers, which are the least common and 
3 0 most significant, occur first. 

Similarly, two address descriptors are considered to 
match if an initial minimum number of keys are equal. 
The same is true with the city descriptors. The 
3 5 inventors have achieved good results with a minimum 

number of three was chosen for the name and the address 
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descriptors, and one as the minimum for the city 
descriptor. 



In a variation of the preferred method, the principle 
5 of inclusion might be used also in authorizing 
payments. In such a variation, a payee name and 
address would be required to include a database 
descriptor in order to effect a match. Database 
descriptors would be structured to include the minimum 

10 number of essential tokens from each name and address 

field. In this variation, additional checking would be 
needed to guard against payee descriptors with 
excessively many additional keys, or with rare 
additional keys. The weakest feasible additional check 

15 would be to require that the payee descriptor may 
include, as a set, at most one database descriptor. 



Name and Address Fields 

2 0 The trusted third party maintains the database 

containing records for customers of the participating 
financial institutions, the billers in the system of 
the present invention. These records include the 
following fields, some of which may be optional: 

25 

(1) Name of the individual or business 

(2) Several address lines 

(3) City 

(4) State 

3 0 (5) Five -digit zipcode 

(6) four-digit zipcode extension 

(7) Identifier of the financial institution 

(8) Biller's account number 

(9) Universal Identification Number (UID) , assigned by 
35 the trusted third party 

(10) E-mail address 

(11) Taxpayer ID. 
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Note that items (7) , (8) and (11) are not distributed 
to participating banks as part of the token/descriptor 
database, and item (10) will only be distributed with 
proper authorization. 

The following record layout for a bank customer field 
is a layout that may be used to model some of the 
techniques described here. Customer Free Format is a 
number 1 or 2 indicating whether the next five fields 
will be treated as a free -form name group or as the 
five distinct fields shown. 



CUSTOMER 


FREE FORMAT 


PIC 


9 (01) 


CUSTOMER 


LAST NAME 


PIC 


X(30) 


CUSTOMER 


FIRST NAME 


PIC 


X(12) 


CUSTOMER 


MIDDLE NAME 


PIC 


X(12) 


CUSTOMER 


NAME PREFIX 


PIC 


X(08) 


CUSTOMER 


NAME SUFFIX 


PIC 


X(08) 


CUSTOMER 


ADDRESS 1 


PIC 


X(31) 


CUSTOMER 


ADDRESS 2 


PIC 


X(31) 


CUSTOMER 


ADDRESS 3 


PIC 


X(31) 


CUSTOMER 


CITY 


PIC 


X(20) 


CUSTOMER 


STATE 


PIC 


X(02) 


CUSTOMER 


ZIPS 


PIC 


9 (05) 


CUSTOMER 


ZIP4 


PIC 


9 (04) 


CUSTOMER 


ACCOUNT NUM 


PIC 


9 (18) 


CUSTOMER 


DFI IDENTIFIER 


PIC 


9 (09) 


CUSTOMER 


UID 


PIC 


9 (10) 


CUSTOMER 


E-MAIL 


PIC 


X(34) 


CUSTOMER 


TAXPAYER ID 


PIC 


9 (16) 



A layout for the generated descriptor file follows. 
The PIC X(03) key fields are treated as 24 -bit binary 
numbers to provide a large number of possible values. 



DESCRIPTOR NAME KEY 



PIC X(03) OCCURS 8 
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10 



15 



DESCRIPTOR 


ADDRESS KEY 


PIC 


X 


(03) 


DESCRIPTOR 


CITY KEY 


PIC 


X 


(03) 


DESCRIPTOR 


STATE 


PIC 


X 


(02) 


DESCRIPTOR 


ZIPS 


PIC 


9 


(05) 


DESCRIPTOR 


ZIP4 


PIC 


9 


(04) 


DESCRIPTOR 


ACCOUNT NUM 


PIC 


9 


(18) 


DESCRIPTOR 


DFI IDENTIFIER 


PIC 


9 


(09) 


DESCRIPTOR 


UID 


PIC 


9 


(10) 


DESCRIPTOR 


E-MAIL 


PIC 


X 


(34) 


DESCRIPTOR 


TAXPAYER ID 


PIC 


9 


(16) 



The notations on the right are in COBOL syntax. The 
numbers within parentheses show field size. These 
sizes are illustrative only. Fields with a 9 0 
specification are numeric, while those with an X() 
specification are alphanumeric. "OCCURS" shows that 
the field is repeated some number of times. 



The DESCRIPTOR NAME KEY items are encoded keys formed 
2 0 from a CUSTOMER name, using the fields from CUSTOMER 
LAST NAME through CUSTOMER NAME SUFFIX. DESCRIPTOR 
ADDRESS KEY items are encoded keys formed from CUSTOMER 
ADDRESS lines 1 through 3. DESCRIPTOR CITY KEY items 
are encoded keys formed from the CUSTOMER CITY field. 
25 The remaining descriptor items are identical to the 
corresponding items in the CUSTOMER record. 

These layouts are merely an example of the type of 
record layouts that may be used. 

30 

Finally, in any of the variations above, the definition 
of match may be relaxed so that two name and address 
descriptors are regarded as matching if the name 
descriptors match and one of the following three cases 
35 holds: 
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(1) Address, city and state match; or 

(2) Address and zip5 match; or 

(3) Zip 5 and zip4 match. 



5 This criterion is illustrative only. The bank could 
alter the exact rules that it chooses to use. There is 
no need for all participating banks to adopt precisely 
the same criterion for a match. Only those procedures 
of the banks affecting the operations at the trusted 
10 third party need to be standardized; any materials 

furnished by the trusted third party to the banks to 
help them to implement the system would also be 
uniform. 



15 In the normal course of events, once the payor's 

entered name and address have been tokenized, encoded, 
and a match found in bank C's descriptor database, UID 
payments from bank C are transmitted to the trusted 
third party as part of files of other ACH transactions 

2 0 already originated by participating financial 

institutions. As was discussed above, the ACH message 
format is altered in the present invention to 
substitute the UID in place of the account number. A 
special identifier flag, for example all 9's, is 

25 substituted for the routing number. After a UID is 
received by the TTP from the payor's home banking 
system and recognized as such by the presence of the 
special identifier, it is used by the TTP, and 
particularly by the trusted third party computer system 

30 50, to retrieve from the TTP's central database 14 the 
payee's bank routing and account number. Once this 
information has been ascertained, the routing and 
account numbers are substituted for the special 
identifier and UID, respectively, and the message is 

35 transmitted to payee's bank B 16, crediting payee's 
bank account for the amount to be paid by the entity 
initiating payment. 
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The retrieval involves a lookup, performed by the 
trusted third party computer system 50 in the central 
database 14, and substitution in the ACH message of the 
UID supplied by bank C with the payee's account number 
5 and the special identifier with the routing/transit 
number of the payee's bank B. After the substitution 
is made, the transaction takes the same route as any 
other ACH transaction in the ACH network. 

10 Because the trusted third party previously has been 
supplied with all the payee account numbers, neither 
the payor nor bank C need know payee's bank account 
number or the bank the payee uses . 

15 Database Maintenance at Trusted Third Party 

For the present invention to work properly, bank 
customers must be able to be reliably identified by 
their name and address information. To make the system 
20 work at a suitably high confidence level, database 

maintenance carried out at the trusted third party is 
utilized to ensure that the confusion of one name and 
address with another will rarely occur. 

2 5 As was discussed above, the database is updated 

periodically as needed to make sure the customer name 
and address information is kept up to date, as well as 
to take into account additional participating banks. 
However, checking for name similarity at database 

3 0 update time cannot, by itself, ensure that such 

confusion does not occur. The maintenance program can 
only compare names and addresses that already have been 
entered into the system; it cannot know whether 
customers of banks not yet in the system may have name 
35 and address fields similar to some currently on file. 
However, if an effort is made to bring as many banks 
and institutions as possible in a given area into the 
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system during a given time period, then the likelihood 
of errors from this source will be minimized. Use of 
taxpayer ID would also prevent such errors. 



5 Maintenance Design Goals 



The maintenance goals given below reflect a concern for 
potential problems that might become important when the 
database becomes very large, with perhaps tens or 
10 hundreds of millions of entries. The design goals 
include : 



(A) Every Name/Address (N/A) must be associated with 
exactly one UID. Personal or business N/A's with 

15 several accounts would have a UID associated only 

with one account, usually the first one entered 
into the system. UID's could be associated with 
each of several accounts for the same legal 
entity, as specified by rules that may be adopted, 

2 0 provided that means are supplied to distinguish 

the N/A fields in some way, for example by the 
addition of box or department numbers . 

(B) Pursuant to (A) , the system must establish with 
25 confidence that any two N/A' s i„ the database are 

in reality different. This will be referred to as 
the identity problem. Again, use of taxpayer ID 
would resolve the identity problem. 

30 (C) The subset/superset problem: This is the problem 
of determining whether, given any two 
corresponding fields of two N/A records, the set 
of tokens in the field of the first record is a 
subset of the set of tokens in the corresponding 

35 field of the second. In such a case, the first 

record will be called a subset of the second. The 
records of such a pair may easily be confused, 
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since merely omitting one or more keys from one 
N/A could produce the other. If the two records 
have the same zipcode, then the situation must be 
reported to the financial institutions involved in 
5 a warning report. It may also be desirable to 

postpone assigning a UID to a new entry that has 
this relationship with an existing record. If the 
zipcodes are different, the two entries could be 
flagged so that home banking customers (i.e., 
10 payors) would be required to supply a zipcode with 

either of these two N/A fields. The warning to 
the financial institution might be omitted in this 
case . 



15 (D) The phonetic misspelling problem: This is the 
problem of determining whether two distinct N/A 
entries in the database have descriptors 
consisting of the same phonetically encoded keys. 
One such phonetic encoding technique is Soundex. 

2 0 Then one N/A entry could be transformed into the 

other by misspelling one or more words in a 
phonetically plausible manner. Actions to be 
taken in such cases might be the same as in (C) 
above; or as determined by the governing body. 

25 

Note that (C) and (D) could occur together. That is, 
two N/A entries might fall into case C if certain words 
in the entries were plausibly phonetically misspelled. 
By using the methods to be described, both C and D as 
30 well as their combined manifestations can be detected. 



The flow of information to be distributed among the 
participants that is required to implement the 
electronic funds transfer method and system of the 
3 5 present invention is shown at Fig. 7. 
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As shown in Fig. 7, trusted third party 13 is first 
supplied with customer account information from 
participating banks and other financial institutions. 
The central database 14 is generated, from the supplied 
5 information, and is resident in a computer system (not 
shown) at trusted third party 13 . 

The central database 14 stores, among other 
information, name and address information, taxpayer ID 

10 if available, bank routing/transit numbers and DDA 
accounts for all bank customers who are potential 
receivers of ACH payments. Participating banks supply 
this information to the trusted third party for 
inclusion in the database. Potential receivers of the 

15 ACH payments can be any customer of any participant. 

Upon receipt by the trusted third party 13 , the 
customer records are added to the central database 14. 
The name and address information supplied by 
2 0 participating banks forms a Customer Name and Address 
file at the TTP. This file is used by the TTP to 
create the descriptor database. A token list is formed 
from the name and address list. The list is in table 
form and includes a second column given the encoded 

2 5 value to be assigned to each toker. during encoding. 

This list is used at the TTP to encode each name and 
address and to form an associated descriptor. The 
collection of descriptors, with UID's assigned by the 
TTP appended thereto, is sent to banks, such as bank C, 

3 0 together with the token list (lookup table) to enable 

bank C to encode tokens corresponding to consumer- 
entered names and addresses and to compare the 
generated descriptor with those stored in the database 
of descriptors supplied by the TTP. 

35 

A key advantage of the present invention is that the 
routing numbers and account numbers are supplied by the 
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participating banks to the TTP but are not transferred 
to the various home banking systems, such as bank C. 
Note that bank C may function both as a participating 
bank and the home banking system. 

5 

The trusted third party database is periodically 
revised to include updates received from participating 
financial institutions. Home banking systems also 
preferably periodically receive updates to their 
10 token/descriptor database. 

As discussed above, the test for a match at home 
banking systems, such as bank C, must be extremely 
strict, to avoid false matches. However, in reviewing 
15 the descriptor database of all customers, the TTP may 
utilize certain techniques which require less stringent 
matching criteria . 

One such technique is descriptor inclusion. Descriptor 

2 0 inclusion may be utilized at the TTP to help ensure 

against the possibility that one name and address might 
be confused with another. Such confusion may occur if 
one set of keys includes another, so that merely 
omitting keys from one descriptor could produce the 
25 other. 

If taxpayer ID is not available, then in generating the 
database 14 at the TTP, it is important that an 
inclusion check be made to see if matches exist between 

3 0 descriptors generated from different name and address 

information. For example, if one bank customer is 
"National Mortgage Bank", while another customer is 
"National Bank of Mortgage", because of the fact that 
the encoded keys for "National", "Bank" and "Mortgage" 
35 are present in the descriptors that would be generated 
from each name, it is possible that a false match could 
be declared at the bank. In order to prevent this 
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occurrence, it is advisable that when the database is 
generated at the TTP, an inclusion check is performed 
to determine whether such a situation exists. In order 
to keep the system free of such events, certain 
5 maintenance steps should be performed at the TTP. 

Fig. 8A illustrates inclusion between name fields of 
two descriptors. As shown in the figure, each encoded 
key in the top descriptor field is included in the 
10 bottom descriptor field, which could lead to confusion 
if keys are left out for the customer represented by 
the bottom descriptor. 

At the TTP, in order to check for the occurrence of 
15 inclusion in the descriptor database, the entire file 
of descriptors is sorted. To test for inclusion, the 
first descriptor is compared with, that is, an 
inclusion check, to be described below, is performed 
with each descriptor having the same first entry. 

2 0 Since, as in Fig. 8A, inclusion may exist even where 

first entries do not match, shifting of the first group 
in each descriptor is performed, as shown in Fig. 8B, 
so that each entry is placed first in one shifted 
version of the descriptor. All of the shifted 
25 descriptors are included in the sorted file of 

descriptors when the inclusion check is performed. 

Shifted descriptors 

To carry out a matching of a database descriptor file 

3 0 with itself to check for descriptor inclusion in batch 

mode, the file of including descriptors (overfile) is 
augmented to contain multiple descriptors for each of 
its N/A descriptors. The additional descriptors are 
produced by shifting the name group within the original 
3 5 descriptor left, one place at a time, dropping the most 
significant encoded key at each step. The file of 
descriptors not so augmented is referred to in the 
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following discussion as the " under f ile" . The test for 
inclusion determines which descriptors, if any, in the 
underfile exhibit inclusion with respect to the 
overf ile . 

5 

In batch matching, two sorted files of descriptors are 
read in tandem, and records are compared only when 
their two first keys are equal. As a result, the 
number of pairs of descriptor records that must be 

10 compared is greatly reduced. However, unless the 

shifted descriptors are added to the file of including 
descriptors (overf ile) as discussed above, many 
inclusions will be missed. This method yields good 
efficiency when inclusion checking is to be carried out 

15 for entire files using batch methods. 

When the first of two descriptors is included in the 
second, the situation is as shown in Fig. 8A. In that 
figure, each key in the upper descriptor also appears 

2 0 in the lower descriptor. Fig. 9 is a flow chart 

showing the steps for a program that checks whether one 
descriptor, UNDERREC, from an underfile of descriptors, 
is included in another descriptor OVERREC from an 
overf ile of descriptors. The program illustrated in 

25 Fig. 9 comprises the ''have inclusion?" determination at 
S5 in the match program flowchart shown in Fig. 10 
discussed below. 

In Fig. 9, the key fields in the descriptors to be 
30 compared are indexed from zero. Index variable J is 
used for the UNDERREC and K is used to index the 
OVERREC. The "J too large" check is performed before 
the check for the value of UNDERREC [J] . 

35 Although a three-way diamond is used in the flowchart 
to reduce the number of blocks in the diagram, only a 
few computer languages (e.g., Fortran) actually permit 
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a three-way test in one statement. Therefore, the 
process shown by the three-way diamond would normally 
be implemented as two two-way tests. 

5 A description of the logic of the flowchart shown in 
Fig. 9 is as follows: 

First, for given values of J and K, the following 
assumptions (a) and (b) hold (note that they hold 
10 trivially when J=K=0) : 

(a) For any J'<J, UNDERREC [ J' ] =OVERREC [K' ] for 

some K'<K (where J is the current index value of 
the UNDERREC and J' is some previous index value 
15 of the UNDERREC and where K is the current index 

value of the OVERREC and K' is some previous index 
value of the OVERREC) . 

(b) For the current J, when the top diamond S200 in 
20 Fig. 9 is entered, UNDERREC [J] is a key that has 

not yet been found in OVERREC. This is true 
because no duplicated keys are present in any 
descriptor. 

25 At step S100, index variables J and K are initialized 
to zero. At step S2 00 it is determined whether the 
currently indexed key of the UNDERREC is less than, 
greater than, or equal to the currently indexed key of 
OVERREC. If UNDERREC [J] is greater than OVERREC [K] , 

3 0 then there can be no inclusion. This is because, as 

discussed above, each and every descriptor is sorted in 
descending order. Therefore, if this OVERREC [K] is 
smaller than this UNDERREC [J] , later members of OVERREC 
can only be smaller, and by assumption (b) , UNDERREC [J] 

3 5 has not yet been found in OVERREC. 



WO 99/56219 



PCT/US99/09064 



- 40 - 

If UNDERREC [J] is equal to OVERREC [K] , then inclusion 
cannot so far be ruled out and the comparisons must 
continue . J is incremented and a check is made at S400 
to see if any keys remain in UNDERREC to be compared. 

5 

If J is too large (index out of range) or UNDERREC [J] = 
0, then there are no more, nonzero keys in the UNDERREC 
to be compared and inclusion exists, otherwise, K is 
incremented at S600. A check is made, at S700 to 
10 determine if any more nonzero keys remaining in 

OVERREC, If no more keys remain in OVERREC, there is 
no inclusion, by assumption (b) . If more keys remain 
in OVERREC, the flow of operation returns to step S200. 

15 If, at S200, UNDERREC [J] is less than OVERREC [K] , the 
program immediately proceeds to S600 to increment the 
index value of OVERREC. 

The following observations can be made with reference 

20 to assumptions (a) and (b) : 

When J is found to be too large, at S400, 
inclusion has occurred, since UNDERREC [J'] was a 
key found in OVERREC for all smaller J' by (a) . 
Otherwise, (a) and (b) continue to hold for the 

25 larger value of J, since in order to increase J at 

S300 it must be true that UNDERREC [J] =OVERREC [K] . 

When K is increased at S600, it must be true that 
UNDERREC [J] has not been found in OVERREC, by 
3 0 assumption (b) . So, if the new value of K is too 

large, there is no inclusion. Otherwise (a) and 
(b) continue to hold for the larger value of K, 
since UNDERREC [J] is not equal to OVERREC [K] 
before K is incremented. 

35 

If, at S200, UNDERREC [J] >OVERREC[K] , then by (b) 
UNDERREC [J] has not yet been found in OVERREC. 
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This OVERREC [K] is too small to equal UNDERREC [J] , 
and later members of OVERREC are even smaller. So 
there can be no inclusion. 



5 The match program compares two files of descriptors, 
the overfile and the underfile, and finds all pairs of 
records (matches) such that the underfile descriptor is 
included in the overfile descriptor. Fig. 10 is a flow 
chart illustrating operation of the match program. 

10 

For a match to be declared, the name, address, and city 
groups must all be pairwise related by inclusion. The 
state and zipcode records must simply be equal, or be 
"close" as defined by a criterion such as those 
15 discussed above. 



In general, the flowchart can be viewed as consisting 
of: 

(a) An outer loop that performs a serial read of the 
20 overfile of including descriptors. 



(b) An inner loop in which a comparison is made of 
each overfile record with all records of the 
underfile that have the same first key as the 
overfile descriptor. This inner loop has loop 
index R. REC is the actual key (record number) of 
the first record of the underfile that has the 
same first key as the current overfile record. It 
is incremented only when the inner loop has 
completed. At each step of the inner loop: 

(b.l) R is used as the actual key of the 
underfile. 

(b.2) For each such underfile record, a check for 
inclusion ("have inclusion?") is performed. 
This block is detailed in Fig. 9. 
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(b.3) When there is inclusion, a match record 
giving both sequence numbers is written. 
However, output of the match record is 
suppressed if the matching records are the 
5 same record, that is, have the same account 

number at the same bank. 

Fig. 11 is job flow for a batch matching job. The 
descriptor generator is described above; it generates 

10 the two descriptor files. The file containing shifted 
descriptors is used as the file of including 
descriptors, i.e., the over- file. The other descriptor 
file is used as the underfile of included descriptors 
in the match. Both descriptor files are in sorted 

15 order at the start. In this sort, the entire record is 
used as sort key, and the sort is in ascending order. 

The match program (described in detail in Fig. 10) 
finds all pairs of descriptors from the two files such 
20 that the under- descriptor record is included in the 

over- descriptor record. Pairs with identical under and 
over records are suppressed; they are the trivial 
inclusions of a descriptor in itself, and so are not 
significant . 

25 

The resulting match records need contain only sequence 
numbers from the two matching records . 

A variation using the U.S. Government Standard Hashing 
30 Algorithm (SHA) to hash the descriptors will now be 
discussed. It may be considered desirable to use 
hashed descriptors (via SHA) to reduce the dispersal of 
customer information among the various banks and to 
reduce the size of the descriptor record. This would 
3 5 entail hashing the entire descriptor as a whole. 

However, any such use of hashing introduces some minute 
additional risk of misidentif ication, since distinct 
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descriptors could theoretically map to the same hash 
value. This minute additional risk can probably be 
more than offset by increasing the maximum number of 
encoded keys in the pre -hashed descriptor, thus 
5 reducing the possibility of error due to the maximum 
descriptor size being exceeded. Since SHA reduces the 
descriptor to a fixed maximum size, this pre -hashed 
increase in size carries a cost only to the TTP , not to 
the participants. 

10 

The main disadvantage of using hashing in this manner 
is that the only matching criterion that can be used at 
the banks with a hashed descriptor is exact (all or 
nothing) matching. No more subtle comparisons, such as 
15 partial equality, inclusion, or distance methods, would 
be possible. 

Distance Functions 

2 0 A variation on the subset/superset problem discussed 

above will now be discussed. The goal is to provide a 
way to ensure that names of distinct UID's will not be 
confused. 

25 The N/A subset relationship described in <C) above can 
be generalized. Consider distance functions, also 
called a metrics. Given two sets S and T, the set 
difference S-T consists of those elements of S that are 
not also in T. Let #(S-T) denote the number of 

30 elements in this set. Then 

Define: dist (S,T) =# (S-T) +# (T-S) 

This defines a metric that measures the distance 
35 between the two sets in a particular sense. Metrics 

are a standard mathematical device having the following 
three properties : 
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For all sets R, S, and T, 

(1) If dist (S,T)=0 then S=T, 

(2) dist (S, T)=dist(T, S) 

5 (3) dist (R, S) +dist (S,T) >=dist (R,T) [>«is read "is 
greater than or equal to"] 

The function defined above satisfies these conditions. 
There are many variations on this definition that also 
10 satisfy the three conditions. For example, defining 

dist2 (S,T) =max(# (S-T) , # (T-S) ) 

yields another function dist2 which also satisfies (1) 
15 through (3) . 

Even better metrics may be defined using the relative 
frequencies of the tokens. Rather than counting the 
tokens in the difference sets with one adds the 

2 0 negative logarithms of the relative frequencies of the 

tokens in these difference sets. In this way rare 
words will contribute more to the distance than common 
words . 

25 Having made such a definition, it may then be asked for 
any name and address entry in the database: What is 
the minimum distance from this entry to another entry? 
The greater this minimum distance, the smaller is the 
chance that a user error can transform one entry into 

3 0 the other. If necessary, in a variation of this system 

the techniques of (C) and (D) above could be modified 
to report any instances where entries closer than a 
given minimum distance exist in the database. Each 
positive result could trigger the same actions 
35 described there. 



Encoder Maintenance 
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Encoder features are preferably fixed once and for all, 
as far as is possible. This is because changing the 
encoding table forces changes to the entire file of 
encoded descriptors. Thus, encoder table changes would 
5 be made only at infrequent intervals when considerable 
computer resources and time are available to compute 
new codes for all records. 

The main features of the simple encoder supplied to 
10 participating banks are the ability to: 

(1) supply a token with an encoded value stored in a 
field of fixed size within the computer, 

(2) define synonyms and noise words with the same 
encoded value or no encoded value, respectively, 
and 

(3) indicate the relative rarity of the more common 
words for use in ordering keys within a 
descriptor. 

All of these features are embodied in the assignment of 
encoded values to tokens. In particular, lower encoder 
values usually indicate a more common token. Token 
number one should therefore be the most common token. 
However, this correspondence between encoded value and 
token frequency is not terribly critical. So, 
infrequent updates should be sufficient to ensure 
efficient operation. 

3 0 II. Electronic Bill Presentment 

In addition to facilitating payments to billers, the 
system of the present invention can also be used in 
reverse to allow billers to present bills to consumer's 
35 (potential payors) . Such a system would utilize the 
UID database resident at the TTP to transmit an ACH 
message to the potential payor's home banking system. 



15 



20 



25 
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In the bill presentment system, companies or 
individuals that wish to bill electronically send 
billing data to the TTP. The TTP uses the UID database 
to route these bills electronically to the home banking 
5 system to present the bills. The bills are delivered 
to the home banking system in ASC X12 format using the 
810 or 811 transaction set. 

The biller in this system delivers a file containing 
10 consumer bills in X12 format to the TTP. The TTP 
routes the consumer's bill in accordance with the 
routing information contained in the database. 
Optimally, this would involve routing the bill to the 
consumer's bank in X12 format. The consumer's bank 
15 routes the bill to its home banking system and presents 
it to the consumer using a proprietary (or open) 
interface that the bank uses to communicate with its 
customers . 

20 If the consumer is willing to pay the bill, it would do 
so by flagging the bill for payment using the interface 
supplied by its bank. Since the bill was received by 
the bank in X12 format, it would be able to route the 
payment through the appropriate payment network. 

2 5 Accompanying the payment would be X12 remittance data 

created from the original X12 invoice. Assuming the 
ACH network is used, the payment would be carried in 
either a Consumer Initiated Entry (CIE) or Corporate 
Trade Exchange (CTX) transaction. The accompanying X12 

3 0 remittance would be appended to the CTX or CIE as 

addenda records. The payment would pass through the 
ACH network and be delivered to the biller' s receiving 
bank. The receiving bank would credit the account of 
the biller, and pass the X12 remittance to the company. 

35 

As an alternative electronic bill presentment method, 
banks that do not currently offer home banking, do not 
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want to develop bill presentment on their home banking 
systems, or simply want to provide multiple access 
methods for their customers, can offer bill presentment 
through the Internet. Such a web-based bill 
5 presentment system would be customized for each 

participating bank. Consumers gain access to a bill 
presentment web site through the web site of the 
participating bank. Participating banks provide a link 
on their web page to the bill presentment web site. 
10 The bill presentment web site may be managed by each 
individual bank, or operated by an automated clearing 
house, such as NYACH. 

Where the web site is managed by the automated clearing 
15 house, billers deliver information to the clearing 
house in the same manner as in the home banking bill 
presentment option discussed above. Instead of 
forwarding billing data to the participating bank's 
home banking system, data for each consumer is kept on 
20 a secure system at the clearing house. This system is 
connected, off -net, to the web-based bill presentment 
server. 

To utilize the system, a consumer logs in at the bill 
25 presentment site, or alternatively, uses a secure 
browser and certificate issued by his or her bank. 
After being successfully authenticated at the bill 
presentment server, the consumer is shown a summary of 
bills available for payment. The consumer then may 
30 click on any bill he or she wishes to examine. The 
bill presentment server then sends an inquiry to the 
clearing house system. The billing information is sent 
back to the bill presentment server, converted to HTML, 
and displayed to the consumer. 

35 

The consumer can then indicate a willingness to pay the 
bill by clicking on a payment icon associated with the 
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presented bill. Payment orders may be collected by the 
clearing house system, where they can be converted into 
an ACH payment in consumer initiated entry (CIE) 
format, or corporate trade exchange (CTX) format. 
5 These ACH payments are forwarded in batches to the 
consumer's bank for balance verification and 
origination into the ACH network. 

The embodiments discussed above are illustrative and 
10 are not intended to limit the scope of the present 

invention to the particular method of (or system for) 
carrying out the invention described therein. The 
scope of the invention is to be interpreted broadly, in 
view of the appended claims . 
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WHAT IS CLAIMED IS: 

1. A funds transfer system for facilitating 
electronic funds transfer between a payor and a payee 
by means of an intermediate trusted third party, said 
system comprising: 

a payor station including a device for electronic 
communication of a payment order, said payment order 
comprising the payee's name, address and an amount owed 
by the payor to the payee; 

a home banking system including a computer 
structured to communicate electronically with the payor 
station, to receive the payment order, and with the 
trusted third party; 

a trusted third party system associated with the 
trusted third party, said trusted third party system 
comprising a computer structured to communicate 
electronically with both the home banking system and a 
bank of the payee; 

said home banking system computer being operable, 
upon receipt of the payment order from the payor 
station, to generate a universal identifier number 
uniquely identifying the payee and to transmit 
electronically the universal identifier number to the 
trusted third party via a communication with the 
trusted third party system; and 

said trusted third party system computer being 
operable, in response to receipt of the universal 
identifier number from the home banking system, to 
identify the payee as a party to receive payment, to 
generate a routing/ trans it number of the bank of the 
payee and the payee's account number from the universal 
identifier number, and to communicate electronically 
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with the bank of the payee to facilitate transfer of 
the amount owed to the payee's account to the bank of 
the payee. 

2. A funds transfer system according to claim 1, 
wherein the home banking system computer has stored 
therein a database, supplied by the trusted third 
party, including name and address information of the 
payee and the universal identifier number, and not 
including corresponding routing/transit number, account 
number and taxpayer ID information of the payee . 

3. A funds transfer system according to claim 2, 
wherein said home banking system computer is operable 
to generate the universal identifier number as part of 
at least one ACH message, together with a special 
identifier. 

4. A funds transfer system according to claim 3, 
wherein the trusted third party system computer is 
operable to identify the payee's routing/transit and 
account number using the received universal identifier 
to facilitate the transfer of the amount owed to the 
payee ' s account . 

5. A funds transfer system according to claim 4, 
wherein said home banking system computer is operable 
to generate the ACH message such that the universal 
identifier number resides in an account number field 
and the special identifier resides in a routing/ trans it 
number field; and wherein the trusted third party 
system computer further comprises: 

means for recognizing the ACH message that 
includes the special identifier as a message requiring 
special handling; and 

means for substituting respectively the payee's 
account number and payee's bank routing/transit number 
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for the received universal identifier and special 
identifier in the ACH message. 

6. A funds transfer system according to claim 2, 
operable with at least one participating institution, 
the payee being one of a plurality of customers of the 
one participating institution, and wherein the name and 
address information in the database comprises a 
descriptor for each of said plurality of customers of 
the at least one participating institution, each 
descriptor comprising numerical information 
corresponding to characters forming the name and 
address of one of the plurality of customers. 

7. A funds transfer system according to Claim 6, 
wherein said payor station device communicates the 
payment order such that it comprises character 
information corresponding to the name and address of 
the payee; and wherein the home banking system computer 
comprises : 

means for encoding the character information 
forming the payment by assigning a numerical value to 
identified nonblank character strings present in the 
character information; 

means for forming a name and address descriptor 
using the encoded numerical values; and 

means for comparing the formed name and address 
descriptor with the database descriptors until a match 
is found, 

said home banking system computer being operable 
to transmit to the trusted third party the universal 
identifier number associated with the matching database 
descriptor. 

8. A funds transfer system according to claim 7, 
wherein said home banking system computer is operable 
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to transmit the universal identifier number in at least 
one ACH message. 

9. A funds transfer system according to claim 7, 
wherein said encoding means includes a lookup table to 
associate nonblank character strings with respective 
corresponding numerical values. 

10. A funds transfer system according to claim 9, 
wherein said encoding means uses hashing to encode 
character strings corresponding to rare words. 

11. A funds transfer system according to claim 3, 
operable with at least one participating institution, 
the payee being one of a plurality of customers of the 
one participating institution, and wherein the trusted 
third party has stored therein a master database 
containing previously collected information, including 
name, address, account number and routing number 
information of each of said plurality of customers of 
the at least one participating financial institution; 
and 

wherein said funds transfer system includes means 
for forming the database stored in the home banking 
system computer from the master database. 

12. A method for transferring funds electronically 
between a payor and a payee by means of an intermediate 
trusted third party, said method comprising the steps 
of: 

upon receipt by the trusted third party of a 
universal identifier number uniquely identifying the 
payee and generated, in response to a payment order 
from the payor, by a home banking system of the payor 
from information stored on a database resident at the 
home banking system, finding, using a table lookup at 
the trusted third party using the received universal 
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identifier number as a key, a routing/ transit number of 
the payee's bank and the payee's account number to 
identify the payee as a party to receive payment, the 
routing/transit number of the payee's bank and the 
payee's account number being known only to the trusted 
third party; and 

communicating, by the trusted third party, with 
payee's bank to facilitate transfer of an amount owed 
by the payor to the payee to the payee's account in the 
payee ' s bank . 

13. A method according to claim 12, further comprising 
the steps of: 

generating the database at the trusted third 
party, the database including name and address 
information of the payee and the universal identifier 
number uniquely identifying the payee, and not 
including corresponding routing/transit number, account 
number and taxpayer ID information of the payee, and 

distributing, before said finding step, the 
database to the home banking system. 

14 . A method according to Claim 13 , wherein the 
universal identifier is received by the trusted third 
party from the home banking system as part of at least 
one ACH message, together with a special identifier. 

15 . A method according to Claim 14 , wherein the 
trusted third party identifies the payee's 
routing/ trans it and account number using the received 
universal identifier to facilitate the transfer of the 
amount owed to the payee's account. 

16. A method according to Claim 15, wherein in the ACH 
message received from the home banking system the 
universal identifier resides in an account number field 
and the special identifier resides in a routing/transit 
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number field; the method further comprising the steps 
of: 

recognizing, by the trusted third party, the ACH 
message that includes the special identifier as a 
message requiring special handling; and 

substituting, by the trusted third party, 
respectively the payee's account number and payee's 
bank routing/ trans it number for the received universal 
identifier and special identifier in the ACH message. 

17. A method according to claim 13, wherein the 
payment order from the payor comprises the payee's 
name, address and the amount owed by the payor to the 
payee . 

18. A method according to claim 17, wherein the payee 
is one of a plurality of customers of at least one 
participating institution availing itself of said 
method and wherein the name and address information in 
the database comprises a descriptor for each of said 
plurality of customers, of the at least one 
participating institution, each descriptor comprising 
numerical information corresponding to characters 
forming the name and address of one of the plurality of 
customers . 

19. A method according to Claim 18, wherein the 
payment order comprises character information 
corresponding to the name and address of the payee, and 
the home banking system performs the substeps of: 

encoding the character information by assigning a 
numerical value to identified nonblank character 
strings present in the payment order character 
information; 

forming a name and address descriptor record using 
the encoded numerical values; 
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comparing the formed name and address descriptor 
with the database descriptors until a match is found; 
and 

transmitting to the trusted third party the 
universal identifier number associated with the 
matching database descriptor. 

20. A method according to claim 19, wherein said 
generating step subjects each database descriptor to a 
hashing algorithm and after said forming step the 
formed named and address descriptor is subjected to the 
hashing algorithm, and wherein the comparing step 
compares the hashed value of the name and address 
descriptor with the hashed values resident in the 
database . 

21. A method according to claim 19, wherein in said 
transmitting substep, the home banking system transmits 
the universal identifier number in at least one ACH 
message . 

22. A method according to claim 19, wherein in said 
encoding substep, a lookup table is used to associate 
nonblank character strings with respective 
corresponding numerical values. 

23. A method according to claim 22, wherein the 
encoding substep uses a hashing algorithm to encode 
character strings corresponding to rare words. 

24. A method according to claim 14, wherein the payee 
is one of a plurality of customers of at least one 
participating institution availing itself of said 
method and wherein the trusted third party performs the 
step of previously collecting information including 
name, address, account number and routing number 
information of each of said plurality of customers, of 
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the at least one participating financial institution 
for use in generating a master database, resident at 
the trusted third party, from which the distributed 
database is formed. 

25. A funds transfer system for facilitating 
electronic funds transfer between a home banking system 
of a payor and an account of a payee, said system 
comprising: 

a trusted third party structured to communicate 
with both the home banking system and a bank of the 
payee maintaining payee's account, 

means associated with said home banking system for 
transmitting a universal identifier number to said 
trusted third party in response to receipt by said home 
banking system of a payment order from the payor, said 
universal identifier number uniquely identifying the 
payee ; 

means associated with said trusted third party 
operable in response to receipt of the universal 
identifier number from the home banking system to 
identify the payee as a party to receive payment, and 
for converting the universal identifier number so as to 
identify the routing/ trans it number of the payee's bank 
and the payee's account number; and 

means associated with said trusted third party for 
communicating with payee's bank to facilitate payment 
in accordance with payor's payment order to payee's 
account . 

26. A method for electronic bill presentment between a 
biller and a payor by an intermediate trusted third 
party, said method comprising: 

generating, by the trusted third party, a database 
including name and address information of the payee and 
a universal identifier number uniquely identifying the 
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payee, and distributing the database to a home banking 
system of the payor; 

receiving, at the trusted third party, a biller 
order from the biller, the biller order comprising the 
payor's name, address and an amount to be paid by the 
payor to the biller; 

upon receipt by the trusted third party of the 
biller order, generating, at the trusted third party, a 
bill routing message and transmitting the bill routing 
message to the payor's home banking system, the message 
including the universal identifier number corresponding 
to the payor; and 

upon receipt by the home banking system of the 
bill routing message from the trusted third party, 
routing, by the home banking system, a bill to the 
payor corresponding to the bill routing message. 

27. a method according to Claim 26, wherein the bill 
routing message comprises an ACH message, the ACH 
message being formed based at least in part upon 
routing information resident in a master database 
resident at the trusted third party. 

28. A method of electronic funds transfer between a 
payor and a payee by an intermediate trusted third 
party, the trusted third party having previously 
distributed to a home banking system of the payor a 
database including universal identifier numbers 
uniquely identifying accounts including that of the 
payee; said method including the steps of: 

receiving, at the home banking system, a payment 
order from the payor; 

upon receipt by the home banking system of the 
payment order, identifying, at the home banking system, 
the universal identifier number uniquely identifying 
payee's account from information stored in the 
database ; and 
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transmitting, by the home banking system, the 
universal identifier number identified in said 
identifying step, to the trusted third party to 
facilitate payment to payee's account. 

29. A computer- readable medium for storing data for 
access by an application program being executed on a 
data processing system resident at a trusted third 
party that has been supplied with confidential 
information of customers of at least one participating 
institution, said medium comprising: 

a data structure stored in said computer- readable 
medium, said data structure including information 
resident in a database used by said application program 
and comprising: 

a plurality of descriptors, each descriptor 
including a set of indicia identifying name, address, 
and the confidential information for one of the 
customers of the at least one participating 
institution, and a universal identifier uniquely 
identifying the one customer. 

30. A computer- readable medium according to Claim 29, 
wherein the database of descriptors is structured so as 
to eliminate any descriptors whose set of indicia 
constitutes a subset of the set of indicia of any other 
descriptor, in order to ensure uniqueness of 
descriptors . 

31. A computer- readable medium according to Claim 29, 
wherein the database is structured to minimize the 
possibility that any one descriptor will be confused 
with any other descriptor by using distance functions 
to require a minimal distance between the sets of 
indicia included in respective descriptors. 
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32. A computer- readable medium according to Claim 29, 
wherein the database is structured to minimize the 
possibility that similar sounding name and address 
information does not encode to a same descriptor by 
using phonetic encoding techniques in preparation of 
the database. 

33. A computer- readable medium according to Claim 29, 
wherein the confidential information comprises 
routing/ trans it number and account number information 
associated with each customer. 

34. A method of transferring funds from a home banking 
system of a payor to an account of a payee, comprising 
the steps of: 

upon receipt by the home banking system of a 
payment order from the payor that includes character 
information, encoding the received character 
information by assigning a numerical value to 
identified nonblank character strings present in the 
received character information; 

forming a descriptor of indicia identifying the 
payee using the encoded numerical information; 

comparing the formed descriptor with database 
descriptors stored in a database supplied by a trusted 
third party until a match is found; and 

transmitting a universal identifier, associated in 
the database with the matching database descriptor and 
uniquely identifying the payee, to the trusted third 
party to facilitate payment to payee's account. 

35. A web-based bill presentment method for presenting 
bills by a biller to a payor using a trusted third 
party having a resident database including an e-mail 
address of the payor, the payor being a customer of a 
bank that has a bill presentment server, said method 
comprising : 
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receiving, at the trusted third party, a bill 
presentment order from the biller; and 

in response to an inquiry from the bill 
presentment server of payor's bank, transmitting 
billing information of the biller to the payor's bank, 
which in turn, by means of the bill presentment server, 
presents the bill for display to the payor using the e- 
mail address of the payor. 

36. A web-based bill presentment method according to 
Claim 35, wherein display means available to the payor 
are linked to the bill payment server, and the payor 
indicates a willingness to pay the bill by clicking a 
payment icon displayed by the display means and 
associated with the bill. 

37. A method of correlating between at least two 
entities by an intermediate trusted third party, said 
method comprising the steps of: 

receiving, by the trusted third party, a universal 
identifier number uniquely identifying a first one of 
the at least two entities and generated in response to 
a inquiry from a second one of the at least two 
entities from information stored on a database; and 

generating, at the trusted third party, from the 
received universal identifier number confidential 
information relating to the first one of the at least 
two entities to identify the first one, the 
confidential information being known only to the 
trusted third party. 

38. A method according to claim 37, further comprising 
the steps of : 

generating the database at the trusted third 
party, the database including name and address 
information of the first one of the at least two 
entities and the universal identifier number uniquely 
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identifying the first one, and not including 
corresponding confidential information of the first 
one , and 

distributing, before said confidential informati 
generating step, the database so as to facilitate 
access to the database by the second one of the at 
least two entities. 
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